home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SGI Developer Toolbox 6.1
/
SGI Developer Toolbox 6.1 - Disc 4.iso
/
public
/
patch
/
README.SGI
< prev
next >
Wrap
Text File
|
1994-08-01
|
11KB
|
247 lines
toolbox/public/patch
Often, software updates (especially for public domain packages such as
GNU) are distributed in the form of context diffs.
The "patch" utility will automagically insert the contents of the diff
file into the original source.
This package is being re-distributed as received from the Free Software
Foundation, which in turn was received from Larry Wall
(lwall@netlabs.com). Anyone may distribute this freely, as long as you
abide by the restrictions contained in the README file.
The Makefile and the patch executable (built on IRIX 4.0.4) are
included here. The Makefile generated by the "Configure" script was
modified to use SGI's "install" utility. To install the patch
executable and the man page onto your IRIS workstation without
recompiling, execute:
su
./install.patch
If you wish to recompile patch, copy this entire directory to a local
disk, and execute make. If you encounter a problem and wish to rebuild
the configuration, remove "Makefile", "config.h", and "config.sh".
Then run the "Configure" script and rerun make (or "make install").
A copy of the man page follows.
----------------------------------------------------------------
PATCH(1) UNIX Programmer's Manual PATCH(1)
NAME
patch - a program for applying a diff file to an original
SYNOPSIS
patch [options] orig diff [+ [options] orig]
DESCRIPTION
Patch will take a patch file containing any of the three
forms of difference listing produced by the diff program and
apply those differences to an original file, producing a
patched version. By default, the patched version is put in
place of the original, with the original file backed up to
the same name with the extension ".orig", or as specified by
the -b switch. You may also specify where you want the out-
put to go with a -o switch. If diff is omitted, or is a
hyphen, the patch will be read from standard input.
Upon startup, patch will attempt to determine the type of
the diff file, unless over-ruled by a -c, -e, or -n switch.
Context diffs and normal diffs are applied by the patch pro-
gram itself, while ed diffs are simply fed to the ed editor
via a pipe.
Patch will try to skip any leading garbage, apply the diff,
and then skip any trailing garbage. Thus you could feed an
article or message containing a context or normal diff to
patch, and it should work. If the entire diff is indented
by a consistent amount, this will be taken into account.
With context diffs, and to a lesser extent with normal
diffs, patch can detect when the line numbers mentioned in
the patch are incorrect, and will attempt to find the
correct place to apply each hunk of the patch. As a first
guess, it takes the line number mentioned for the hunk, plus
or minus any offset used in applying the previous hunk. If
that is not the correct place, patch will scan both forwards
and backwards for a set of lines matching the context given
in the hunk. All lines of the context must match. If patch
cannot find a place to install that hunk of the patch, it
will put the hunk out to a reject file, which normally is
the name of the output file plus ".rej". (Note that the
rejected hunk will come out in context diff form whether the
input patch was a context diff or a normal diff. If the
input was a normal diff, many of the contexts will simply be
null.)
If no original file is specified on the command line, patch
will try to figure out from the leading garbage what the
name of the file to edit is. In the header of a context
diff, the filename is found from lines beginning with "***"
or "---", with the shortest name of an existing file win-
ning. Only context diffs have lines like that, but if there
is an "Index:" line in the leading garbage, patch will try
to use the filename from that line. The context diff header
takes precedence over an Index line. If no filename can be
intuited from the leading garbage, you will be asked for the
name of the file to patch.
(If the original file cannot be found, but a suitable SCCS
or RCS file is handy, patch will attempt to get or check out
the file.)
Additionally, if the leading garbage contains a "Prereq: "
line, patch will take the first word from the prerequisites
line (normally a version number) and check the input file to
see if that word can be found. If not, patch will ask for
confirmation before proceeding.
The upshot of all this is that you should be able to say,
while in a news interface, the following:
| patch -d /usr/src/local/blurfl
and patch a file in the blurfl directory directly from the
article containing the patch.
If the patch file contains more than one patch, patch will
try to apply each of them as if they came from separate
patch files. This means, among other things, that it is
assumed that separate patches will apply to separate files,
and that the garbage before each patch will be examined for
interesting things such as filenames and revision level, as
mentioned previously. You can give switches (and another
original file name) for the second and subsequent patches by
separating the corresponding argument lists by a '+'. The
argument list for a second or subsequent patch may not
specify a new patch file, however.
Patch recognizes the following switches:
-b causes the next argument to be interpreted as the
backup extension, to be used in place of ".orig".
-c forces patch to interpret the patch file as a context
diff.
-d causes patch to interpret the next argument as a direc-
tory, and cd to it before doing anything else.
-D causes patch to use the "#ifdef...#endif" construct to
mark changes. The argument following will be used as
the differentiating symbol. Note that, unlike the C
compiler, there must be a space between the -D and the
argument.
-e forces patch to interpret the patch file as an ed
script.
-l causes the pattern matching to be done loosely, in case
the tabs and spaces have been munged in you input file.
Any sequence of whitespace in the pattern line will
match any sequence in the input file. Normal charac-
ters must still match exactly. Each line of the con-
text must still match a line in the input file.
-n forces patch to interpret the patch file as a normal
diff.
-N forces patch to not try and reverse the diffs if it
thinks that they may have been swapped. See the -R
option below.
-o causes the next argument to be interpreted as the out-
put file name.
-p causes leading pathnames to be kept. If the diff is of
the file "b/a.c", patch will look for "a.c" in the "b"
directory, instead of the current directory. This
probably won't work if the diff has rooted pathnames.
-r causes the next argument to be interpreted as the
reject file name.
-R tells patch that this patch was created with the old
and new files swapped. (Yes, I'm afraid that does hap-
pen occasionally, human nature being what it is.) Patch
will attempt to swap each hunk around before applying
it. Rejects will come out in the swapped format. The
-R switch will not work with ed diff scripts because
there is too little information to reconstruct the
reverse operation.
If the first hunk of a patch fails, patch will reverse
the hunk to see if it can be applied that way unless
the -N option is supplied. If it can, the -R switch
will be set automatically. If it can't, the patch will
continue to be applied normally. (Note: this method
cannot detect a reversed patch if it is a normal diff
and if the first command is an append (i.e. it should
have been a delete) since appends always succeed.
Luckily, most patches add lines rather than delete
them, so most reversed normal diffs will begin with a
delete, which will fail, triggering the heuristic.)
-s makes patch do its work silently, unless an error
occurs.
-x<number>
sets internal debugging flags, and is of interest only
to patch patchers.
ENVIRONMENT
No environment variables are used by patch.
FILES
/tmp/patch*
SEE ALSO
diff(1)
DIAGNOSTICS
Too many to list here, but generally indicative that patch
couldn't parse your patch file.
The message "Hmm..." indicates that there is unprocessed
text in the patch file and that patch is attempting to
intuit whether there is a patch in that text and, if so,
what kind of patch it is.
CAVEATS
Patch cannot tell if the line numbers are off in an ed
script, and can only detect bad line numbers in a normal
diff when it finds a "change" command. Until a suitable
interactive interface is added, you should probably do a
context diff in these cases to see if the changes made
sense. Of course, compiling without errors is a pretty good
indication that it worked, but not always.
Patch usually produces the correct results, even when it has
to do a lot of guessing. However, the results are
guaranteed to be correct only when the patch is applied to
exactly the same version of the file that the patch was gen-
erated from.
BUGS
Could be smarter about partial matches, excessively deviant
offsets and swapped code, but that would take an extra pass.
If code has been duplicated (for instance with #ifdef OLD-
CODE ... #else ... #endif), patch is incapable of patching
both versions, and, if it works at all, will likely patch
the wrong one, and tell you it succeeded to boot.
If you apply a patch you've already applied, patch will
think it is a reversed patch, and un-apply the patch. This
could be construed as a feature.
Printed 12/10/87 May 10, 1986 4